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Rare 

• Part of MGS 

• Creatively Lead 

• Multi Title 

- 2-4 360 teams 

- Prototype teams 

- DS / Handheld Team 

• Support Teams 

- Shared Technology 
Group 

-Audio Department 
-Art Asset Group 
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Shared Technology Group 

Background 
Motivation 
Development 

- Initial plan and focus 

Review of initial approach 


STG: Background 
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History 

-“RnD” Setup in 1999; 5-6 inexperienced 
developers, 1 lead 

- Currently 20 developers, 2 leads and 
producer 

Used by all console titles since 2000 

- First title: Starfox ( Game Cube ) 

- Six major titles so far 


STG: Motivation 
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Why was the group setup? 

Reduce Duplication 

- Over five different engines on N64 

- Development cost expected to increase 

Disseminate best practice 

- Best of breed 
Share research 
Support art and design 
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STG: Initial Plan 

Interview teams to see what they do 
Develop a shared engine (“rl”) 

Ready for teams moving from N64 to GC 
Game development model 


STG: Initial Focus 

• Response to perceived problems 

• Strong focus on art-pipeline 

- Reflection of creativity lead development 

- Respected art tool in previewer 

- Artist authored shaders 

• Emphasis on runtime performance 

- Expectations from single platform history 



Review 


N 


J 




Mates tdi 


Successes 

-Accurate art tool reflection 

- High runtime performance 

But key weak areas 

- Development Process 

- Distribution and Support 
-Client Relationships 

We examine these next 
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Technology Development 

Then and Now 
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Technology: Then 


Artist directed technology 

- Confused communication 

Focus on “next-gen” features circa 2000 

- High-order surfaces, physics, ... 

Too much emphasis on runtime 

- Single platform culture 

- Naive content expectations 
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Technology: Then 

Reactive development 

- Polish and optimisation postponed 

- Favours vocal minority 

Too little experience 

- Code quality 

- Focus on “cool” features 
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Technology: Now 

• Pro-active Coordination with teams 
-Agile development ( scrum-like ) 

- Transparent “ring-fencing “ of capacity 

• Producer 

• Peer code reviews 

• Components based 

• Technology is not the hardest part... 
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Component Based 

• Not building an engine 

- Clients already had engines .. 

• Set of independent components 

• Allows for middleware 

• Clients take suitable components 

• Components support customisation 

- Important in getting support of graphics 
engineers 
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us Component 

• Animation 

• Rendering 

• Art tool support 

- Plug-ins 

- Exporters 

• Art-pipeline 

- Max and Maya 


Catalogue 

• Tools 

- Asset management 

- World building 

- Asset previewer 

• Fonts 

• Data reflection 

• Collision detection 

• Maths 

• Profiling 
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Kameo: Elements of Power 

- Used all components, but with custom lighting 

Perfect Dark Zero 

- Custom Deferred Renderer built on top of 
existing pipeline components 

- Havok for physics and collisions 

Viva Pinata 

- Only animation and low-level components 

- Co-existed with an existing renderer 


Component Use 
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Distribution and Support 


Then and Now 
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Distribution and Support: Then 

• Did not really consider distribution 

• Initially planned quarterly releases 

• But taking a new version painful 

- Development cycles out of sync 
-Asset and code build times 

• Poor model for team code changes 

- Re-integration of local changes 
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Distribution and Support: Now 

• We see ourselves as much a service as a 
product 

- “fire and forget” does not work for middleware 

• Improved build quality 

• Deprecation policy 

• Better source control tools ( source depot ) 

• Better customisation 

• Case officers 
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The role of the case officer 

• Developer allocated to each game in 
production 

- Prototypes do not generally need one 

• Bridge between the game team and STG 
-Accountable developer 

• Has a personal stake in the product 

• Responsible for arguing the clients case 

- On-site customer in agile methodologies 


/At 

i 



RARE 


Microsoft 

gamej0£studios 




t 



Client Relations 




Then and 
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Client Relations: Then 

• Critically important 

• STG did fit into the development culture 

- Competitive teams 

• Poor feedback between teams and STG 

• An Us-vs-Them situation developed 


Client Relations: Now 

• Involve teams in monthly sprint planning 

• Quarterly product review meetings 

• Game teams mentor STG developers 

• Case officers again 

• Informal monthly technical lead meetings 
-with biscuits! 

• All new starts come through STG 
-Removes the “us-and-them” distinction 


Was it worth it? 

• Modest team sizes ( *30 ) outside of 
crunch 

• Three titles shipped in last two years 

• Game teams less technology focused 

• Improved development atmosphere 

• Preserved core values 

- Still art / design lead 

- Still have strong team identities 


Future 
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Binary changes still a problem 

- Case officers feel the pain 

Documentation 

- Recruitment is difficult 

Tools still need work 

Build times a problem 

- How to balance re-factoring against cost to 
clients? 


Summary: Lessons Learnt 

Client Relationships 

- Critical to build culture where good will is 
assumed on both sides 

- Face to face meetings 

- Case officers 

Support and Distribution 

Software as service 

Development 

- components 
-Agile development 




